Feat/cli extended functionality #409
Conversation
packages/cli/src/index.ts
Outdated
| process.env.NODE_NO_WARNINGS = "1"; | ||
|
|
||
| await yargs(hideBin(process.argv)) | ||
| .scriptName("proto-kit") |
There was a problem hiding this comment.
let's change this to protokit. I know I'd get really mad about that dash in the middle :)
packages/cli/src/index.ts
Outdated
| ) | ||
| .demandCommand() | ||
| .help() | ||
| .command( |
There was a problem hiding this comment.
So - I don't really like the structure of this file - it's just a long spaghetti of commands.
We should find a pattern that allows this to be structured in a more modular way.
An idea would be that every file (command) implements a interface with a function command<T, R>(argv: Argv<T>): Argv<R> and internally calls return argv.command(....)
Then this file would only collect all those implementations and iterate over them
packages/cli/src/index.ts
Outdated
| } | ||
| ) | ||
| .command( | ||
| "lightnet:wait-for-network", |
There was a problem hiding this comment.
So I had imagined this as a bit more reusable. Something like protokit run deposit where run says "execute a script" and deposit is the name of the script.
Where the script can either be one of our predefined scripts or a user-supplied one from the starter kit.
Now to realize this we have a few tools available that yargs gives us:
We can do nested commands: https://github.com/yargs/yargs/blob/main/example/nested.mjs
We can also let yargs go through the directories automatically and scaffold the command structure: https://github.com/yargs/yargs/blob/main/example/command_hierarchy.mjs
Some combination of this would be the most intuitive, create a mechanism to structure this on the framework side and then plug in the starter-kit side into the same mechanism
There was a problem hiding this comment.
More information on the folder stuff: https://github.com/yargs/yargs/blob/main/docs/advanced.md#providing-a-command-module
packages/cli/src/index.ts
Outdated
| } | ||
| ) | ||
| .command( | ||
| "lightnet:faucet <publicKey>", |
…-functionality-update
…y-update Feat/cli extended functionality update
Description
This PR extends the Proto-Kit CLI with new commands for environment setup, bridge , settlement deployment, and explorer management.
New Commands
Environment Management
env:createproto-kit env:createBridge Operations
bridge:deposit <tokenId> <fromKey> <toKey> <amount>tokenId- Token identifierfromKey- Sender's private key (or environment variable name)toKey- Recipient's public key (or environment variable name)amount- Amount to deposit (in whole units)proto-kit bridge:deposit 1 SENDER_KEY RECIPIENT_KEY 100bridge:redeem <tokenId> <toKey> <amount>tokenId- Token identifiertoKey- Recipient's public key (or environment variable name)amount- Amount to redeemproto-kit bridge:redeem 1 RECIPIENT_KEY 100bridge:withdraw <tokenId> <senderKey> <amount>tokenId- Token identifiersenderKey- Sender's private key (or environment variable name)amount- Amount to withdrawproto-kit bridge:withdraw 1 SENDER_KEY 100Settlement Deployment
settlement:deployproto-kit settlement:deploysettlement:token:deploy <tokenSymbol> <feepayerKey> <receiverPublicKey> [mintAmount]tokenSymbol- Symbol for the token (e.g., "USDC")feepayerKey- Private key for paying deployment feesreceiverPublicKey- Public key to receive minted tokens[mintAmount]- Amount to mint initially (default: 0)proto-kit settlement:token:deploy USDC FEEPAYER_KEY RECEIVER_KEY 1000Lightnet Utilities
lightnet:wait-for-networkproto-kit lightnet:wait-for-networklightnet:faucet <publicKey>publicKey- Destination public key (or environment variable name)proto-kit lightnet:faucet B62qnzbXQcUoQFnjvF4Kog6KfNsuuSoo7LSLvomPeak2CLvEYiUqTlightnet:initializeproto-kit lightnet:initializeDeveloper Tools
generate-keys [count][count]- Number of key pairs to generate (default: 1)proto-kit generate-keys 5explorer:start-p, --port- Port to run on (default: 5003)--indexer-url- GraphQL endpoint URL for the indexerproto-kit explorer:start -p 3000 --indexer-url http://localhost:8081/graphqlAll commands that interact with environment variable can be handled through two options:
Option 1:
--env-path(File-based)Loads environment variables from a
.envfileOption 2:
--env KEY=valuePasses environment variables directly as command-line arguments. Can be used multiple times.
closes #353